Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 2/csmp-v2-001.txt

Text File | 1994-12-08 | 37.4 KB | 957 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 04 Jan 93       Volume 2 : Issue 1

Today's Topics:

    Accessing MPW 411 from THINK C
    How to store file references/names ?
    Deadman programming - how to reset?
    calling MacTCP from ioCompletion routine
    How can you discover which debugger is installed?
    AppleEvents for Print server 3.0?
    Fixing Apples serial drivers. How???



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, there is
no way that I know of for you to post articles to the group.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

Organization: Stanford Linear Accelerator Center
Date: Tuesday, 1 Dec 1992 19:07:26 PST
From: Nobukazu Toge <[e-mail]>
Subject: Accessing MPW 411 from THINK C

This is a small QuicKeys sequence file to access MPW's 411
facility from within THINK C using ToolServer.  You need to have
QuicKeys + CEIAC running for this to work.

I am posting this, because (1) it may help someone who want to
use MPW 411 rather than THINK Reference, and (2) if someone can
point out how to speed it up that would be nice [the sequence,
as is, is a bit slow... you'll see.]

- - Nobu Toge ([e-mail]
             [e-mail]    <-- preferred
             [e-mail])

(This file must be converted with BinHex 4.0)

---------------------------

From: [e-mail] (Gerald Siek)
Subject: How to store file references/names ?
Date: 15 Nov 92 12:31:44 GMT
Organization: University of Paderborn, Germany

Hiya Wizards!

What is the best (easiest?) way to store file informations in a preferences
file?   My application reads an initialization file on startup and I want
to give the user the possibility to choose what file should be read.
I've heard that I should NOT try to store entire file names.   Can I simply
bring up a file dialog and the store the file reference number?   Or does
this number change as files and directories change on the hard disk?

Any suggestions?

Thanks in advance!
    Jerry
- --
  Gerald Siek  -  [e-mail]  -  University of Paderborn, Germany

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Date: 15 Nov 92 17:29:19 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] writes:
>What is the best (easiest?) way to store file informations in a preferences
>file?   My application reads an initialization file on startup and I want
>to give the user the possibility to choose what file should be read.
>I've heard that I should NOT try to store entire file names.   Can I simply
>bring up a file dialog and the store the file reference number?   Or does
>this number change as files and directories change on the hard disk?
>
    If you are a System 7 only product, then the best way would be to
create an alias to the file (via NewAlias) and then store the aliasHandle
in your prefs file.  If not, or if you will be working on both 6 & 7, then
you need to create a new data structure which will store a volume NAME (
volume reference numbers (vRefNums) are not valid across boots), a directory
ID (dirID) and a file name.  With that information you can get back to those
files.

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 16 Nov 92 23:24:16 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Leonard Rosenthol) writes:

>    If you are a System 7 only product, then the best way would be to
>create an alias to the file (via NewAlias) and then store the aliasHandle
>in your prefs file.  If not, or if you will be working on both 6 & 7, then
>you need to create a new data structure which will store a volume NAME (
>volume reference numbers (vRefNums) are not valid across boots), a directory
>ID (dirID) and a file name.  With that information you can get back to those
>files.

DirID aren't that great either as I found out after I had to restore
a disk from a backup. :-( The dirID's all changed of course. I guess you need
a full pathname AND the volname,dirid,filname triplet to really be safe.
And anyone that looked into a alias can tell you that it does contain
the full path name. Damn you Apple! :-) (Do what I say not as I do. For years
Apple has been bellowing: "don't use full pathnames" What did they end up
using for aliases?)


Matt
- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (E.J. Draper)
Date: 17 Nov 1992 16:17:14 GMT
Organization: U.T.M.D. Anderson Cancer Center

In article <[e-mail]> Matt Mora, [e-mail] writes:

>And anyone that looked into a alias can tell you that it does contain
>the full path name. Damn you Apple! :-) (Do what I say not as I do. For
years
>Apple has been bellowing: "don't use full pathnames" What did they end
up
>using for aliases?)

So?  Why shouldn't they?  Programmatically FSSpecs are great, but are
utterly useless when things breakdown or when dealing with the Alias
Manager's idiosyncracies.  Say, for instance, we need to move 2.4
gigabytes of patient Images from our local RAID storage system to
permanent storage on our UNIX server. In the process ALL ALIASES
referencing files on the RAID will be INVALIDATED but the volumes'
structure will be identical. Well, what do we do now?  How does the
physician's conferencing software find a patient's scan?

All we need to do is call GetAliasInfo().  From this we can obtain the
full path name that was stored in the Alias handle. If Apple hadn't
bothered to use and store the original path name we'd be totally out of
luck!

Good Apple. Good Apple. ;-)


      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 17 Nov 92 22:13:06 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Matt Mora) wrote:
>
> And anyone that looked into a alias can tell you that it does contain
> the full path name. Damn you Apple! :-) (Do what I say not as I do. For years
> Apple has been bellowing: "don't use full pathnames" What did they end up
> using for aliases?)

Well, there's a smiley in there, so I guess I don't really need to point
out that Apple also writes directly to the screen, reads and sets hardware
registers, examines and changes private fields of data structures, calls
undocumented traps, parses up the region structure, etc...

Actually, the full pathname in the alias structure is only used as a backup
in case the dirID fails. Using both a path of dirIDs and names is a very
powerful technique, and I'm sure Apple wouldn't mind if you decided to
implement one for your application. However, that's a lot of work, and
using a dirID is very simple and works 99.9+% of the time (how often do you
restore a hard disk from tape?)

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Robert M. Fuhrer)
Organization: Computer Science Dept., Columbia Univ.
Date: Tue, 17 Nov 1992 22:59:21 GMT

Of course, being able to use "relative" paths in aliases (e.g., "Up 2 folders,
into the folder named 'Foo'...") would solve the problem much of the time...

Unfortunately, Apple didn't put it in (even though Unix has had this for
years)!
- --

- -- Bob

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 18 Nov 92 17:30:31 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Robert M. Fuhrer) writes:
> Of course, being able to use "relative" paths in aliases (e.g., "Up 2 folders,
> into the folder named 'Foo'...") would solve the problem much of the time...
>
> Unfortunately, Apple didn't put it in (even though Unix has had this for
> years)!

So what does that first argument to NewAlias and ResolveAlias actually do?

Lawrence
thought he was using relative aliases all this while (and had them work,
too)...

+++++++++++++++++++++++++++

From: [e-mail] (Alan Bomberger)
Date: 18 Nov 92 20:32:03 GMT
Organization: Amdahl Corporation, Sunnyvale CA

"How many times do you restore a disk from tape?"

Imagine a Hypertext document with links to hundreds of files.
Do you want to tell the user of a hypertext application that
it will stop working should he ever have to restore his disk
from tape.  Why keep a backup then?

Since you have to keep full path names one wonders why
one would use DirIDs?

To answer you question.  Once is enough to have one
mighty pissed off customer!!

- --
Alan Bomberger     | (408)-992-2748  | [e-mail]
Amdahl Corporation | Opinions are free, worth it, and not Amdahl's

+++++++++++++++++++++++++++

From: [e-mail] (Roger Allen)
Date: 19 Nov 92 16:59:41 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <[e-mail]> [e-mail] (Alan Bomberger) writes:
>Since you have to keep full path names one wonders why
>one would use DirIDs?

This is in case the user moves the folder containing the file to another
location, the volName, dirID and fileName method will work.

BTW, thanks to all of the people in this thread, I hadn't considered that a
something could mess up the dirID and I will be putting that code in my
program...  (SC 16 didn't mention that :^) Isn't c.s.m.p great!

Thanks,
Roger.
- --
> Roger Allen                   | Opinions expressed by me do not        <
> Amdahl Computer Development   | represent the opinions of Amdahl.      <
> [e-mail]           |                                        <

+++++++++++++++++++++++++++

From: [e-mail] (John Hardin)
Date: 24 Nov 92 20:36:05 GMT
Organization: MCC ISD, Austin, Texas

[This is a naive question, I'm sure -- so go easy. :-)]

The consensus for storing file references seems to be storing a volume
name, a directoryID, and a filename.  Given a vRefNum (e.g., as from
SFPutFile), how do I get the corresponding directoryID?

- -jwh
- --
John W. Hardin            phone:  [phone]
MCC                email:  [e-mail]
3500 W. Balcones Center Dr  fax:    [phone]
Austin, TX  78759-6509        uucp:   ...!cs.utexas.edu!milano!hardin

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 25 Nov 92 01:56:40 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail] (John
Hardin) wrote:
>
> [This is a naive question, I'm sure -- so go easy. :-)]
>
> The consensus for storing file references seems to be storing a volume
> name, a directoryID, and a filename.  Given a vRefNum (e.g., as from
> SFPutFile), how do I get the corresponding directoryID?
>
> -jwh
> --
> John W. Hardin            phone:  [phone]
> MCC                email:  [e-mail]
> 3500 W. Balcones Center Dr  fax:    [phone]
> Austin, TX  78759-6509        uucp:   ...!cs.utexas.edu!milano!hardin

Call GetWDInfo.  Pass it the vRefNum you got from SFPutFile and it will
give you the corresponding vRefNum and dirID.  It will also give you a
"procID".  You should set this to zero before calling the function,
and ignore it afterwards.

In my opinion, any time you get a vRefNum (from SFGetFile, SFPutFile
or GetAppFiles), you should immediately convert the vRefNum it gives you
to a vRefNum / dirID pair and use those instead internally.  There are
a couple of excellent reasons for this:

1) Working directories are unstable, and avoiding them is a good thing.
2) It will make converting your program to support aliases, AppleEvents,
and a lot of other stuff much easier, since these things always assume
you support vRefNum/dirID pairs and that you never use working
directories.

Tim Dierks
MacDTS, but I speak for myself

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 30 Nov 92 21:54:09 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Tim Dierks, software saboteur) wrote:
>
> In article <[e-mail]>, [e-mail] (John
> Hardin) wrote:
> >
> > [This is a naive question, I'm sure -- so go easy. :-)]
> >
> > The consensus for storing file references seems to be storing a volume
> > name, a directoryID, and a filename.  Given a vRefNum (e.g., as from
> > SFPutFile), how do I get the corresponding directoryID?
> >
> > -jwh
> > --
> > John W. Hardin            phone:  [phone]
> > MCC                email:  [e-mail]
> > 3500 W. Balcones Center Dr  fax:    [phone]
> > Austin, TX  78759-6509        uucp:   ...!cs.utexas.edu!milano!hardin
>
> Call GetWDInfo.  Pass it the vRefNum you got from SFPutFile and it will
> give you the corresponding vRefNum and dirID.  It will also give you a
> "procID".  You should set this to zero before calling the function,
> and ignore it afterwards.
>
> In my opinion, any time you get a vRefNum (from SFGetFile, SFPutFile
> or GetAppFiles), you should immediately convert the vRefNum it gives you
> to a vRefNum / dirID pair and use those instead internally.  There are
> a couple of excellent reasons for this:
>
> 1) Working directories are unstable, and avoiding them is a good thing.
> 2) It will make converting your program to support aliases, AppleEvents,
> and a lot of other stuff much easier, since these things always assume
> you support vRefNum/dirID pairs and that you never use working
> directories.
>
> Tim Dierks
> MacDTS, but I speak for myself

If you look at the Std File hacks sample code, you'll find the code
we're recommending to use.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

---------------------------

From: Chuck Pliske <[e-mail]>
Subject: Deadman programming - how to reset?
Organization: University of Washington
Date: Wed, 18 Nov 1992 00:35:57 GMT

I have written a "deadman" program, consisting of a faceless bg app with
a TimeManager periodic visit.  The app resets a counter every WNE, and
the TM task counts it down.  If it gets to 0, its time to reset the Mac.

It has been my observation that most crashes involve the mainline portion
of the system, and leave the interrupt system operational.  My problem is
in figuring out a reliable "reset" to use.  In my old hypercharged SE,
the "reset" instruction works just fine and I now have increased
reliability in my unattended system.  However, in the IIfx (7.1) the
reset instruction blanks the screen but does not otherwise reset the
computer.  Any suggestions would be appreciated.

Chuck Pliske

+++++++++++++++++++++++++++

From: [e-mail]
Organization: 4th Dimension BBS
Date: Wed, 18 Nov 1992 11:19:29 EST

Chuck Pliske wrote:

> In my old hypercharged SE,
> the "reset" instruction works just fine and I now have increased
> reliability in my unattended system.  However, in the IIfx (7.1) the
> reset instruction blanks the screen but does not otherwise reset the
> computer.  Any suggestions would be appreciated.

Take a look at the ShutdownManager in IM V, pg. 585. You'd call the _Shutdown
trap with a sdRestart selector (=2) passed on the stack as an integer.

Dave
********************************************************************
System: fourd.com                                Phone: [phone]
Cute quote:  Being a computer means never having to say you're sorry
********************************************************************


+++++++++++++++++++++++++++

From: [e-mail] (Chuck Pliske)
Date: 2 Dec 92 09:48:27 GMT
Organization: University of Washington

Re: Deadman programming - how to reset?

Dave, the "coordinated" shutdown I need to avoid, because I need to
restart *after* the mainline has "crashed", i.e. we can't quit running
jobs, etc.  I ended up using a TM task to count down a global, resetting
it with a mainline "faceless" task, and using the TM task to branch to
Rombase+10 to do the actual reset.  It works pretty well, since most of
my crashes seem to be in the mainline.

Chuck

---------------------------

From: [e-mail]
Subject: calling MacTCP from ioCompletion routine
Date: 29 Nov 92 19:58:29 EST
Organization: Cornell University

     I am wondering whether it is safe to make MacTCP calls from the
interrupt level.  In particular, I am doing asynchronous UDPReads and
would like my ioCompletion routine to return the buffer and queue
another read after processing an incoming packet.  Might I also be
able to do a UDPWrite at that time if the need should later arise?
IM II says that PBControl may move memory; the only clue I could find
in the MacTCP Programmer's Guide was the statement that "you are
not allowed to make further synchronous MacTCP calls from an ASR."
Anybody know the answer?  Thanks
Tim Dorcey

+++++++++++++++++++++++++++

From: [e-mail] (Haavard Nord)
Date: 1 Dec 92 18:47:32 GMT
Organization: Department of Biomedical Engineering

It should be safe to call MacTCP from a (PPC) ioCompletion routine.
I call Sybase OpenClient, which in order calls MacTCP. This works fine,
although I have problems with loading the Sybase segments.
- -hanord
- --
===============================================================================
 Haavard Nord                                        email: [e-mail]
 Dept. of Biomedical Engineering                     phone: [phone]
 Trondheim, Norway                                     fax: [phone]
===============================================================================

+++++++++++++++++++++++++++

From: [e-mail] (David Peterson)
Date: 1 Dec 92 07:29:22 GMT
Organization: University of Southern California, Los Angeles, CA


In article <[e-mail]>, [e-mail] writes:
|>      I am wondering whether it is safe to make MacTCP calls from the
|> interrupt level.  In particular, I am doing asynchronous UDPReads and
|> would like my ioCompletion routine to return the buffer and queue
|> another read after processing an incoming packet.  Might I also be
|> able to do a UDPWrite at that time if the need should later arise?
|> IM II says that PBControl may move memory; the only clue I could find
|> in the MacTCP Programmer's Guide was the statement that "you are
|> not allowed to make further synchronous MacTCP calls from an ASR."
|> Anybody know the answer?  Thanks
|> Tim Dorcey


As long as the calls you are making are asyncronous.

Chaining completion procs together like this works great in MacTCP. Just have
your recieve completion proc do an asyncronous buffer return and another
asyncronous recieve and your app is continuously receiving data without even
knowing about it.

Another thing to try is have the recieve completion proc do an asyncronous
PBWrite and have _its_ completion proc do another asyncronous UDBReceive.
Its a bit hairy at first, and you can vomit enormous amounts of garbage to
your disk before you get it debugged, but afterwards it works great.

- -dave.

---------------------------

From: [e-mail] (Eric Nedervold)
Subject: How can you discover which debugger is installed?
Date: 30 Nov 92 17:40:48 GMT
Organization: Univ. of Wisconsin Dept. of Mathematics

Is there any way to find out within a program which debugger is installed?
I'd like to format my debug strings differently if I'm running with
MacsBug than if I've got the ThinkC debugger.  Is the name secreted away
anywhere like AppName[] is?

- --Eric

+++++++++++++++++++++++++++

From: [e-mail] (Sandra Stewart-Cole)
Date: 2 Dec 92 08:41:57 GMT
Organization: University of Illinois at Urbana

In <[e-mail]>
[e-mail] (Eric Nedervold) writes:

>Is there any way to find out within a program which debugger is installed?
>I'd like to format my debug strings differently if I'm running with
>MacsBug than if I've got the ThinkC debugger.  Is the name secreted away
>anywhere like AppName[] is?

Well, there is no global that does the pure job, however there are possible
ways to tell. For instance, if the Think C Debugger is present, it will show up
as a regular application if you run thru them all with process manager calls.
Not ideal, but if you do it once at the start and set a global it isn't too
painful. Alternatively, you can try checking where the debugger traps
(_Debugger and _DebugStr) are dispatched to, and that can clue you to who is
answering the calls. If you just want to check for the presence of MacsBug,
you should also be able to check the interrupt dispatch table for where a
level 7 interrupt goes. If it is outside RAM, MacsBug isn't about.


---------------------------

From: [e-mail] (Mimir Reynisson)
Subject: AppleEvents for Print server 3.0?
Date: 3 Dec 92 10:39:48 GMT

The title says it all. Does the AppleShare Print server support
apple events and if so which apple events? I'm particularily interested
in the printer queue can I get a copy of the queue via apple events?

Thanks in advance.

+++++++++++++++++++++++++++

From: apple.com (Ben Beasley)
Date: Thu, 3 Dec 1992 16:19:55 GMT
Organization: Apple

The PrintSpooler doesn't support AppleEvents. It doesn't have the bit set in the size
resource for accepting High-Level events and when I ran a  (PPC)browser tool
that application doesn't show up in the "Programs" field.

This has been a request made by developers before for the PrintSpooler, just
thought you should know that your inquary has NOT fallen on deaf-ears.
Regards,

Benjamin Beasley


In article <[e-mail]>, [e-mail] (Mimir Reynisson) writes:
>
> The title says it all. Does the AppleShare Print server support
> apple events and if so which apple events? I'm particularily interested
> in the printer queue can I get a copy of the queue via apple events?
>
> Thanks in advance.

---------------------------

Subject: Fixing Apples serial drivers. How???
From: [e-mail]
Date: Tue, 3 Nov 1992 01:30:52 GMT
Organization: VAX Cluster, Computer Centre, La Trobe University

Does any one have inner knowledge of the Apple serial drivers?

I have written a terminal emulation program based on CommControl
from Faceware, which in turn is based on the CommsToolbox.
This was done because I was using terminal emulators such
as Versaterm Pro (slow) and others to download FORTH source
code to a microcomputer with a FORTH compiler in EPROM.
The Baud rate is either 9600 or 38400. The large amount
of text transfered along with pauses during compilation
requires that the Mac responds properly to handshaking.

In fact indications are that the Mac sometimes ignores
or misses Xoff or even hardware handshaking so overflowing
the input buffer on the micro.

Writing my own terminal emulator was supposed to solve the
problem but it does not. Hence the problem is likely to be
in Apples low level drivers.

Can these drivers be tuned to work better or can they be fixed.
I have written low level drivers for the SCC chip before but
I am reluctant to do this because of possible conflicts with
other interrupt driven hardware in the system such as the
floppy disk drivers.

Thanks in advance Richard Rothwell

P.S. This problem occurs on both a Mac Plus a Mac II and IIfx.

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Date: 3 Nov 92 09:20:23 GMT
Organization: Whole Earth 'Lectronic Link

I don;t know what the original poster was doing wrong, but Apple's serial
drivers certainly do correctly implement handshaking. Anytime anyone prints
on a serial imagewriter, the handshaking does its stuff. Works fine.

+++++++++++++++++++++++++++

From: Alexander M. Rosenberg <[e-mail]>
Date: Tue, 3 Nov 1992 19:21:05 GMT
Organization: Hackers Anonymous

In article <[e-mail]> ,
[e-mail] writes:
>which in turn is based on the CommsToolbox.

Why is it that so many people get this wrong. It's CommToolbox. I've
noticed that generally persons from Australia and England add the 's'
while most USA people use 'Comm ToolBox', which is also wrong.

I guess this is why Byron gave up on correcting people.

(There's only so much us "spelling Nazis" can take.)
- ---------------------------------------------------------------------------
- -  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
- -  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
- -  Palo Alto, CA 94301     -                                - Systems     -
- -  [phone]          - Nobody is my employer so       - :-)         -
- -  [phone]          - nobody cares what I say.       -             -

+++++++++++++++++++++++++++

From: [e-mail] (Jim Cathey)
Date: 3 Nov 92 21:57:11 GMT
Organization: ISC - Bunker Ramo, Spokane, WA

In article <[e-mail]> [e-mail] writes:
>In fact indications are that the Mac sometimes ignores
>or misses Xoff or even hardware handshaking so overflowing
>the input buffer on the micro.

I doubt this.  However, a common characteristic of nearly _all_
current handshaking schemes on serial ports is that up to several
more characters may be sent after flow control is tripped.  That is,
ports aren't guaranteed to shut off at exactly the next character, one
or more may dribble out first.

Now, if your device is particularly dumb (like a TTY 40, for example),
it is unable to accept _any_ further characters after it has triggered
the flow control, and any dribble out the port will be lost.  This is
bad.  For the TTY 40, we had to make a polling driver (non-Mac, btw)
that polled for SR empty before checking flow control and then putting
another character into the SR of the serial controller.  This is nasty.

So, how dumb is your device? If it's a bit-banging microcontroller, or
one that's not interrupt-driven and/or has no FIFO, it's easily possible
that it's unable to see the line for short periods, and could miss
characters.  Not the Mac's fault, though.  Any current system would
probably act the same.

- --
+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

+++++++++++++++++++++++++++

From: [e-mail] (Alen Shapiro)
Date: 3 Nov 92 20:38:09 GMT
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA

In <[e-mail]> [e-mail] (David Phillip Oster) writes:

>I don;t know what the original poster was doing wrong, but Apple's serial
>drivers certainly do correctly implement handshaking. Anytime anyone prints
>on a serial imagewriter, the handshaking does its stuff. Works fine.

My experience has been that with System 7.01, serial io will lose
incomming characters while appletalk is active (I've only tested
this with baud rates 9600 or greater...don't know the lower bound).

I have not tried any tests with my recently installed 7.1. This does NOT
seem to be a buffer overflow problem, rather a "lost interrupt"/character
overrun problem.

Anyone have any experience with 7.1 and serial io with appletalk talking?

- --alen
[e-mail]

ps I have noticed that hardware handshaking is much more severe with 7.1
   i.e. a background serial transfer program stays inactive for longer
   than with 7.01...subjective only...sorry (perhaps this is a MF scheduling
   change?)

+++++++++++++++++++++++++++

From: [e-mail] (Jason Jones)
Date: 4 Nov 92 15:39:03 GMT
Organization: University of Chicago Computing Organizations

In article <[e-mail]> [e-mail] (Alen Shapiro) writes:
>My experience has been that with System 7.01, serial io will lose
>incomming characters while appletalk is active (I've only tested
>this with baud rates 9600 or greater...don't know the lower bound).

In writing a net/modem game last year, I noticed that the serial drivers
would sometimes lose characters while I was playing asynchronous sounds.
This only happened at baud rates of 2400 and higher on the older, 68000
models (and probably has a lot to do with different sound hardware).

The problem was a hardware overflow of the SCC's internal 3-byte buffer,
if I remember right.

Jason.

+++++++++++++++++++++++++++

From: [e-mail] (Warren DeLano)
Organization: Yale University, Department of Computer Science, New Haven, CT
Date: Tue, 17 Nov 1992 16:19:10 GMT

In article <[e-mail]> [e-mail] (Alen Shapiro)
writes:
> In <[e-mail]> [e-mail] (David Phillip Oster)
writes:
>
> >I don;t know what the original poster was doing wrong, but Apple's serial
> >drivers certainly do correctly implement handshaking. Anytime anyone prints
> >on a serial imagewriter, the handshaking does its stuff. Works fine.
>
> My experience has been that with System 7.01, serial io will lose
> incomming characters while appletalk is active (I've only tested
> this with baud rates 9600 or greater...don't know the lower bound).
>
> I have not tried any tests with my recently installed 7.1. This does NOT
> seem to be a buffer overflow problem, rather a "lost interrupt"/character
> overrun problem.
>
> Anyone have any experience with 7.1 and serial io with appletalk talking?
>
I've noticed the same problem with appletalk and hardware handshaking under
System 7 and 7.1.  Although appletalk is not the exclusive cause of the
problem, downloads tend to have many more retries if I am connected to a busy
network.  This problem only occurs for me only on downloading and not
uploading.

> From: [e-mail] (David Phillip Oster)
>
> I don;t know what the original poster was doing wrong, but Apple's serial
> drivers certainly do correctly implement handshaking. Anytime anyone prints
> on a serial imagewriter, the handshaking does its stuff. Works fine.
> This would correlate with the post which said that --
>

Printing to an imagewriter involves sending large amounts of data but not
receiving.  Consequently, only transmit hardware handshaking is used during
printing.  The problems I have seem to involve only receive hardware
handshaking.

Anyone else encountered these symptoms?

========================================================
Warren Lyford DeLano  -  [e-mail]
Box 5061, New Haven, CT 06520 AOL:Warren CIS: 72746,1363
========================================================

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Tue, 17 Nov 92 23:29:18 GMT
Organization: Project GLUE, University of Maryland, College Park


The problem is quite real, and not System 7 specific.  Appletalk
disables interrupts while it gets the packets, and doesn't service the
modem port in the copious free time it has (if a Mac 512 has no free
time to do it, a Q700 ought to have plenty--HEY APPLE!!!!!!! FIX IT!)

So, if during the time Appletalk is getting the packets, more than 3
characters come in on the modem port.... whammo, hardware overrun.
- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Paul Campbell)
Date: 30 Nov 92 16:02:32 GMT
Organization: Taniwha Systems Design

In article <[e-mail]> [e-mail] (Matthew T. Russotto) writes:

>The problem is quite real, and not System 7 specific.  Appletalk
>disables interrupts while it gets the packets, and doesn't service the
>modem port in the copious free time it has (if a Mac 512 has no free
>time to do it, a Q700 ought to have plenty--HEY APPLE!!!!!!! FIX IT!)

The Q700/900/950/FX of course have LESS free time than a Mac 512 because they
use an IOP to talk to the SCC. This is sort of like using an Apple II to
do your LocalTalk and modem access.

    Paul

- --
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
Use up your Quayle jokes now while they're still good "Quayle for Pres. in '94"
     Q: Why is Marilyn Quayle like Marion Barry?
     A: They both suck a little dope.

+++++++++++++++++++++++++++

Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Tue, 1 Dec 1992 12:47:05 GMT

In <[e-mail]> [e-mail] (Paul Campbell) writes:

>>The problem is quite real, and not System 7 specific.  Appletalk
>>disables interrupts while it gets the packets, and doesn't service the
>>modem port in the copious free time it has (if a Mac 512 has no free
>>time to do it, a Q700 ought to have plenty--HEY APPLE!!!!!!! FIX IT!)

>The Q700/900/950/FX of course have LESS free time than a Mac 512 because they
>use an IOP to talk to the SCC. This is sort of like using an Apple II to
>do your LocalTalk and modem access.

The Q700 only uses the 68040.

t have to be slowed down by LocalTalk
t) when the IOPs are ON, but several applications
I like to run (Like, CuBase and Sound Designer and the venerable
SoundEdit) do NOT like the IOP :-(

Cheers,

                        / h+

- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
  "It was, in fact, cool as all get-out.  Fortunately it was a little
   too late (historically speaking) to be groovy."
                     -- Dennis Pelton

+++++++++++++++++++++++++++

From: [e-mail] (Philip Craig)
Organization: Canon Information Systems Research Australia
Date: Thu, 3 Dec 1992 00:36:34 GMT

tte) writes:

>In <[e-mail]> [e-mail] (Paul Campbell) writes:

>>>The problem is quite real, and not System 7 specific.  Appletalk
>>>disables interrupts while it gets the packets, and doesn't service the
>>>modem port in the copious free time it has (if a Mac 512 has no free
>>>time to do it, a Q700 ought to have plenty--HEY APPLE!!!!!!! FIX IT!)

>>The Q700/900/950/FX of course have LESS free time than a Mac 512 because they
>>use an IOP to talk to the SCC. This is sort of like using an Apple II to
>>do your LocalTalk and modem access.

>The Q700 only uses the 68040.

t have to be slowed down by LocalTalk
t) when the IOPs are ON, but several applications
>I like to run (Like, CuBase and Sound Designer and the venerable
>SoundEdit) do NOT like the IOP :-(

Maybe that's because the IOP gives errors. Seriously.

I wrote some high speed serial testing code (just using the normal RAM
Serial driver -- no stuffing around with the Z8530 SCC chip or anything).

It *always* got lots of spurious errors on a IIfx with the IOP turned on.
Switching the Serial Control switch to Compatible fixed these errors.
The IOP has never been a reliable high-speed serial solution. A shame.
- --
   _/_/_/ _/  _/ _/ _/     _/ _/_/_/ _p_h_i_l_i_p_@_r_e_s_e_a_r_c_h_._c_a_n_o_n_._o_z_._a_u   _--_|\
  _/  _/ _/  _/ _/ _/     _/ _/  _/  Phone: [phone]        /      \
 _/_/_/ _/_/_/ _/ _/     _/ _/_/_/   Fax:   [phone]        \_.--._/
_/     _/  _/ _/ _/_/_/ _/ _/     PO Box 313 North Ryde 2113 AUSTRALIA  v

---------------------------

End of C.S.M.P. Digest
**********************